MESSAGE BRIDGING SYSTEM AND METHOD FOR SINGULAR SERVER 



TO SINGULAR OR MULTIPLE EVENT RECEPTION ENGINES 
BACKGROUND OF THE INVENTION 

5 The present invention relates generally to software products for message bridging, 

and more specifically, to a system and method for integrating software products having 
different event message input and output formats. 

During the course of day-to-day business transactions within enterprises, e.g., 
credit card companies, brokerage houses, and airlines, immense amounts of data are 

10 continually recorded. Such entities typically employ enterprise computing, wherein an 
enterprise may comprise a large number of computers of varying type (e.g. mainframes, 
minicomputers, microcomputers and workstations), with multiple hosts, running on 
multiple platforms of varying type. This may be due to internal or external 
reorganizations or mergers of various entities or departments, each with different 

15 computing needs, and thus, a variety of hardware and software to fulfill those needs. On 
a computer scale, enterprises may be as dynamic as the human population. 

One exemplary enterprise component is a storage manager. In an enterprise, 
ongoing backup of enterprise- wide data must be continuously performed, so that, in the 
event the machine storing the original copy of the data fails or is inaccessible, a backup 

20 copy of the data may be retrieved. One exemplary archival system for making and 

restoring such backups is the Tivoli™ Storage Manager (TSM). Such an archival system 
may provide a guarantee for enterprises that their valuable data, which is often an 
enterprise's largest asset, or software, may be restored from an archive in the event the 
original data becomes unavailable. 
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To manage, monitor and/or control the activities of the various enterprise 
components, an enterprise console, e.g. Tivoli™ Enterprise Console (T/EC) is employed. 
The enterprise console uses a plurality of agents or "spies" to gather information about 
the activities of the various enterprise components. Such information is sent to the 
5 enterprise console when problems or faults occur. The enterprise console provides this 
information to an administrator or an information technology resource manager at a 
central location, so that he or she may efficiently deploy information technology or 
consulting services. For example, if a system in a particular department crashes, the 
administrator can send a consultant to that department immediately to resolve the 

10 problem. As another example, if a machine runs out of space, the administrator, on the 
fly, can allocate some more space for that machine. The enterprise console thus allows 
the administrator to remain in one physical location to stay apprised of events taking 
place within the enterprise at any number of physical locations. 

Within a single enterprise, the enterprise console and various enterprise 

15 components have often been developed independently of one another and, additionally, 
may be mature products. For example, the T/EC and TSM were both developed 
independently by different developers working for different companies and have each 
undergone a number of revisions. Today, the T/EC and TSM are owned and supported 
by the same company due to corporate acquisitions, yet there is no standard for 

20 exchanging event messages between the two products. Beyond this specific example, 
similar situations exist with respect to software and hardware components within many 
enterprises as well as outside the enterprise context. 
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As among such various components^ each component, e.g., a backup archive 
product, an enterprise control, a database application, and a web host, has different 
requirements and needs for sending and receiving event messages to and from other 
components. Additionally, each component may have different formats for the event 
5 messages it is able to send and receive, without any single standard in existence. 
Therefore, a translation means must be employed for allowing various 
components to communicate effectively with one another. One translation method 
known in the art is the use of a dedicated hardware device for receiving, translating, and 
sending event messages, e.g., between a Unix machine and a mainframe, between Unix 
Si 10 and a Windows NT™ machine, between a mainframe and a Windows NT^^ machine, or 
in other translations between operating systems. However, many such hardware devices are 

unable to translate event messages between two different types of software, since what 
needs to be translated is how the information is presented, (e.g., how the information is 
'fl ordered in ASCII), and not how the information is stored, (e.g., as binary data). 

15 In the networking field, translations are routinely performed, at various levels 

within layers of a communication protocol, e.g., as between various layers of TCP/IP, or 
between a TCP/IP layer and a NetBEUI, layer. However, translations are not performed 
at the application-to-application layer in this context. 

Sending messages from an enterprise storage management product to an 
20 enterprise event receiver has previously been problematic. Known solutions include the 
use of logfile adapters or reverse engineering of the API for the event receiver. Use of a 
logfile adapter is disadvantageous, as it presents issues with scalability (number of 
processable messages) and resource issues, and a priori knowledge of the messages is 
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required. Reverse engineering the API is disadvantageous, as it presents synchronization 
and resource issues, since every time the API is updated, all of the reverse engineering 
effort must be done again. There also is no guarantee that the reverse engineering efforts 
will be successful after the API has been modified. 
5 SUMMARY OF THE INVENTION 

The present invention provides a software-based system and method for 
facilitating communications between different software systems requiring different event 
message techniques and/or formats by building the receiver's message format into the 
sending software apphcation. For example, as between T/EC and TSM, TSM possesses a 

10 specific component that handles sending messages to the T/EC. Yet, the entire 

apphcation programming interface (API) of the T/EC has not been integrated with the 
TSM. As a result, in the event the API of the T/EC changes, the messages being sent by 
the TSM are locked into a specific format, such that the T/EC may not be able to 
correctly receive those messages. However, the TSM is able to send out an event- 

15 specific, generic TSM message to a plug-in module that loads into a server, typically 
referred to as a userexit. In a system consistent with the present invention, the userexit 
(or other generic adapter) is loaded with a user-defined software module that has 
knowledge of the format of events the server is capable of sending out, as well as the 
format of events the receiver expects to receive. So long as the messages sent and 

20 received maintain the same structure, a system consistent with the invention can translate 
them, thereby allowing messages that do not currently exist to be translatable, once they 
are created. 
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It should be recognized that the invention has utility in a wide variety of contexts 
and is not limited to TSM and T/EC or future releases thereof. The method of the 
invention allows a software product to communicate with another software product, 
simply by modifying a very small module having code that is relatively fast to develop, 
5 debug and test (due to the limited number of lines of code required to be written and/or 
modified), thereby providing integration with other software products, including 
components of an enterprise and other systems involving established, mature, or older 
software products that are otherwise incompatible with one another. 

Specifically, in the context of TSM and T/EC interoperability, the problems 
10 associated with the use of a logfile adapter are resolved by the invention, which does not 
require a prior knowledge of the messages and can send messages to multiple event 
receivers. The problems associated with reverse engineering are resolved by the 
invention, which utilizes the API provided with the event receiver engine. 

In one embodiment, a method for bridging messages between a first and at least a 
15 second application having differing message formats comprises receiving message data 
from the adapter of a first application in a first format; translating and/or parsing the 
received message data into at least a second format; and outputting the translated and/or 
parsed message data to at least the second application. 

In another embodiment, a computer system consistent with the invention 
20 comprises a first application, at least a second application, and a message bridge. The 
first apphcation has an adapter capable of outputting message data in a first format. The 
second application is capable of receiving message data in a second format. The message 
bridge is adapted to receive message data from the adapter of the first application in the 
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first format, translate and/or parse the received message data into at least the second 
format; and output the translated and/or parsed message data to at least the second 
application. 

In a further embodiment, a software module, stored on a computer-readable 
5 medium, for bridging messages between a first and at least a second application having 
differing message formats, comprises instructions for receiving message data from the 
adapter of the first application in a first format; instructions for translating and/or parsing 
the received message data into at least a second format; and instructions for outputting 
the translated and/or parsed message data to at least the second application. 
10 In yet another embodiment, a message bridging apparatus comprises storage 

means for storing computer-readable instructions; instructions, stored in the storage 
means, for receiving message data from a first application in a first format, the first 
application having an adapter; instructions, stored in the storage means, for translating 
and/or parsing received message data into at least a second format; and instructions, 
15 stored in the storage means, for outputting the translated and/or parsed message data to at 
least a second application. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a system diagram of an exemplary enterprise in one embodiment of the 
present invention; 

20 Figure 2 is a system diagram of another exemplary enterprise in one embodiment 

of the present invention; 

Figure 3 is a flow diagram of the message bridging process in one embodiment of 
the present invention.; 
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Figure 4 illustrates an exemplary event source message format, in one 
embodiment of the present invention; 

Figure 5 illustrates an exemplary event receiver message format, in one 
embodiment of the present invention; and 
5 Figure 6 is a table illustrating an exemplary rule-based correspondence between 

the event source and event receiver message formats illustrated in Figures 4 and 5, in one 
embodiment of the present invention. 

DETAILED DESCRIPTION OF THE EMBODIMENTS 
One embodiment of the invention is illustrated in Figure 1, wherein an exemplary 
10 enterprise 10 has an event source 1 1 (e.g., a ISM server) having an adapter 14, an event 
receiver 12 (e.g. a T/EC server), and a message bridge module 13. The event source 1 1 is 
unable to send event messages directly to the event receiver 12 due to incompatible event 
formats. However, the event source 1 1 can instead, via its adapter 14, pass the message 
structure to the message bridge module 13, which translates it appropriately and passes it 
15 along to the event receiver 12 in an appropriate format. 

The message bridge module 13 is dynamically loaded into the event source 1 1 , 
thereby providing a point of integration into another mature software product. The 
message bridge module 13 operates by employing an adapter 14, e.g., a generic adapter, 
or a userexit of the event source 11. In this context, an "adapter" or "userexit" (also 
20 referred to as an "interface adapter") refers to a mechanism for extending the 

functionality of an application by means of an external program that may be written in 
any language and that provides additional control over features, e.g., formatting, 
processing, and selection of data, beyond that available from the application alone. A 
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userexit is typically coded into software by specifying input and output formats for a 
function routine. A pointer to the userexit routine is then set by making an operating 
system call to load the userexit module into the main application's memory/workspace. 
A userexit is a function for the main appUcation that is resolved at the execution of the 
5 application, not at the compilation of the application. Typically, the event source 
appUcation outputs data to the userexit without receiving any confirmation regarding 
whether it was received. Those skilled in the art will recognize that a generic or other 
adapter may be used instead of a userexit. The message bridge module generally resides 
on the same server as the event source, occupying the same memory space from which 
10 the event source application is running. Thus, in effect, the message bridge module 

becomes a part of the event source application by virtue of its location at the userexit. It 
is noted that documentation, either external or internal, of the structures and elements of 
the source application may be needed in creating the message bridge module, depending 
on the manner in which the userexit is exposed. 
15 Exemplary qualified event sources may include, without limitation, TSM, DB2, 

Oracle, SQL applications, PeopleSoft, knowledge management tools, databases, backup 
archive products, database servers, email servers, web servers, large applications used in 
an enterprise environment, applications that have their own message generation events, 
e.g., to signal attention to an administrator monitoring the application, and applications 
20 employing a userexit. Event receivers may include, without limitation, T/EC, DB2, 

Oracle, SQL applications, PeopleSoft, knowledge management tools, databases, backup 
archive products, database servers, email servers, web servers, large applications used in 
an enterprise environment, enterprise management applications, event monitoring 
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applications, and applications adapted to receive messages from other applications that 
have their own message generation events. Event monitoring applications may include 
an application adapted for the sole function of event monitoring or reception, as well as 
an application that has event monitoring or receiving functions merely as one or more 

5 components of the application. 

Another embodiment of the invention is illustrated in Figure 2, wherein an 
exemplary enterprise 20 has an event source 21 (e.g., a TSM server) having an adapter 
24, a plurality of event receivers 22 (e.g. a T/EC server), and a message bridge module 
23, In this scenario, the event source 21 may be integrated with multiple APIs and may 

10 send messages to multiple event receivers 22 expecting messages in different formats. 
The event source 21 is unable to send event messages directly to the event receivers 22 
due to incompatible event formats. However, the event source 21 can instead, via its 
adapter 24, pass the message structure to the message bridge module 23, which parses it 
using appropriate logic, translates it appropriately, and passes it along to one or more of 

15 the event receivers 22 in the appropriate formats. 

An exemplary operation process flow 30 of the invention is illustrated in Figure 3. 
First, the event source application generates 31a message, e.g., out of disk space, backup 
completed, database error. The message is then passed 32 to the userexit. Next, the type 
of message received from the application is determined 33. For example, TSM outputs 

20 five general classes of messages: local server events; events that are forwarded to the 
local server from another server; local client events (i.e., event messages received from 
clients strung off the server, which passes them off to an event monitor, e.g., T/EC); 
events from clients attached to a remote server (which then sends the message to the local 
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server); and control events (e.g. "shutdown" or other such commands). The message is 
subsequently parsed and/or translated 34 using a set of rules appropriate to the 
appUcation. One exemplary rule might be to ignore certain messages from the event 
source that have no counterpart in the event receiver. Another exemplary rule might be 

5 to convert an event message control data into a data structure adapted for receipt by the 
event receiver or event monitor, e.g. a set of Boolean values for an event monitor that 
accepts messages having only Boolean values, or a string to be received by a T/EC. A 
further exemplary ruleset might permit a T/EC to demand data not supplied by the TSM, 
wherein the ruleset supplies a reasonable substitute and returns it to the T/EC in a format 

10 expected by the T/EC. After the parsing and/or translation, the parsed and/or translated 
message is pushed 35 to the event receiver, which receives 36 the message in its expected 
format and acts accordingly. Depending on the application programming interface (API) 
of the event receiver, further additional steps in the aforementioned process might 
include, e.g., error handling cases for message transmission 37 or advanced features, such 

1 5 as message queuing 38. 

By the aforementioned process, the power of the event receiver API may be 
utilized without requiring extensive coding effort in creating the apphcation. Thus, two 
or more products may be developed simultaneously and independently, and the 
aforementioned process may be used to integrate the two by means of a message bridge 

20 module residing in the userexit of the event source appUcation, without requiring code 
modification of the existing products. 

Figures 4 and 5 illustrate an exemplary event source message format 40 and event 
receiver message format 50, respectively, in one embodiment of the invention. In the 
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example shown, the message formats correspond to those of TSM and T/EC, 
respectively. The principal difference between the message formats of TSM and T/EC is 
that TSM employs data structures 41, whereas the TEC expects and eventually parses, 
upon receipt, a semi-colon delimited string containing a number of fields 51, with several 

5 required fields 52, including eventClass, source, sub_source, origin, sub_origin, 
adapter_host, hostname, date, and severity. 

Referring now to Figure 6, in conjunction with the message formats 40, 50 
illustrated in Figures 4 and 5, a table 60 illustrates an exemplary rule-based 
correspondence between the TSM and T/EC message formats. Table 60 includes 

10 columns for the data provided by TSM 61, data expected by T/EC 62, appropriate 

substitutions 63, and notes 64 regarding some of the variances between TSM and T/EC 
message formats. The message bridge module 23 contains appropriate instructions for 
receiving data in a first format, e.g. TSM data 61, translating the data received, and 
outputting data in a second format, e.g., T/EC data 62. 

15 As those skilled in the art will recognize, the present invention may be embodied 

in a variety of systems, methods, and/or computer program software embodiments. 
Accordingly, the present invention may take the form of a computer program product on 
a computer-usable or computer-readable storage medium having computer-usable or 
computer-readable program code embodied in the medium for use by or in connection 

20 with an instruction execution system. In the context of this document, a computer-usable 
or computer-readable medium may be any medium that can contain, store, communicate, 
propagate, or transport the program for use by or in connection with the instruction 
execution system, apparatus, or device. The computer-usable or computer-readable 
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medium may be, for example, but is not limited to, an electronic, magnetic, optical, 
electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation 
medium. More specific examples of the computer-readable medium include, without 
limitation, a magnetic, optical, or other fixed or removable computer disk, a random 
5 access memory (RAM), a read-only memory (ROM), an erasable programmable read- 
only memory (EPROM or Flash memory), and a portable compact disc read-only 
memory (CD-ROM). It is noted that the computer-usable or computer-readable memory 
could even be paper or another suitable medium upon which the program is printed, as 
the program can be electronically captured, via, for instance, optical scanning of the 
10 paper or other medium, then compiled, interpreted, or otherwise processed in a suitable 
manner, if necessary, and then stored in a computer memory. 

Those skilled in the art should recognize that an integrated circuit (IC) chip or 
other such hardware device could be implemented to perform a translation algorithm 
consistent with the invention, e.g., using logic gates. It should further be recognized by 
15 those skilled in the art that such an IC chip could be fixedly or removably attached to, or 
integrated with, a printed circuit (PC) board, which could then be installed in a computer 
system. In this scenario, the userexit within the event source application would be loaded 
with an address for the module performing the translation, such that the algorithm could 
be implemented in either hardware or software, depending on real-time processing 
20 requirements and cost considerations. 

It will be appreciated by those skilled in the art that although the functional 
components of the exemplary embodiments of the system of the present invention 
described herein may be embodied as one or more distributed computer program 
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processes, data structures, dictionaries and/or other stored data on one or more 
conventional general purpose computers (e.g. IBM-compatible, Apple Macintosh, and/or 
RISC microprocessor-based computers), mainframes, minicomputers, conventional 
telecommunications (e.g. modem, DSL, satellite and/or ISDN communications), memory 
5 storage means (e.g. RAM, ROM) and storage devices (e.g. computer-readable memory, 
disk array, direct access storage) networked together by conventional network hardware 
and software (e.g. LANAVAN network backbone systems and/or Internet), other types of 
computers and network resources may be used without departing from the present 
invention. 

10 One or more networks discussed herein may be a local area network, wide area 

network, internet, intranet, extranet, proprietary network, virtual private network, a 
TCP/IP-based network, a wireless network, an e-mail based network of e-mail 
transmitters and receivers, a modem-based telephonic network, an interactive telephonic 
network accessible to users by telephone, or a combination of one or more of tiie 

15 foregoing. 

The invention as described herem may be embodied in a computer residing on a 
server or server system, and input/output access to the invention may comprise 
appropriate hardware and software to allow supervised or unattended execution of 
various operations of the invention, in real-time and/or batch-type transactions. 
20 Additionally, those skilled in the art will recognize that the various components of the 

present invention may be remote from one another, and may further comprise appropriate 
communications hardware/software and/or LANAVAN hardware and/or software to 
accomplish the fimctionality herein described. 
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Each of the functional components of the present invention may be embodied as 
one or more distributed computer program processes running on one or more 
conventional general purpose computers networked together by conventional networking 
hardware and software. Each of these functional components may be embodied by 

5 running distributed computer program processes (e.g., generated using "full-scale" 

relational database engines such as IBM DB2™, Microsoft SQL Server Sybase SQL 
Server™, Oracle 7.3 ™, or Oracle 8.0'^^ database managers, and/or a JDBC interface to 
link to such databases) on networked computer systems (e.g. comprising mainframe 
and/or symmetrically or massively parallel computing systems such as the IBM SB2 ™ 

10 or HP 9000 ™ computer systems) including appropriate mass storage, networking, and 
other hardware and software for permitting these functional components to achieve the 
stated function. These computer systems may be geographically distributed and 
connected together via appropriate wide- and local-area network hardware and software. 
Primary elements of the invention may be server-based and may reside on hardware 

15 supporting an operating system such as Microsoft Windows NT/2000™ or UNIX. 

Alternatively, the aforesaid functional components may be embodied by a 
plurality of separate computer processes (e.g. generated via dBase Xbase MS 
Access™ or other "flat file" type database management systems or products) running on 
IBM-type, Intel Pentium '^^ or RISC microprocessor-based personal computers 

20 networked together via conventional networking hardware and software and including 
such other additional conventional hardware and software as may be necessary to permit 
these functional components to achieve the stated functionalities. In this alternative 
configuration, since such personal computers typically may be unable to run full-scale 
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relational database engines of the types presented above, a non-relational flat file "table" 
(not shown) may be included in at least one of the networked personal computers to 
represent at least portions of data stored by a system according to the present invention. 
These personal computers may run the Unix, Microsoft Windows NT/2000™ or 

5 Windows 95/98/ME/XP ™ operating systems. The aforesaid functional components of a 
system according to the present invention may also comprise a combination of the above 
two configurations (e.g. by computer program processes running on a combination of 
personal computers, RISC systems, mainframes, symmetric or parallel computer systems, 
and/or other appropriate hardware and software, networked together via appropriate 

10 wide- and local-area network hardware and software). 

In one embodiment, source code may be written in an object-oriented programming 
language using relational databases. Such an embodiment may include the use of 
programming languages such as C++. Other programming languages which may be used 
in constructing a system according to the present invention include Java, HTML, Perl, 

15 UNIX shell scripting, assembly language, Fortran, Pascal, Visual Basic, and QuickBasic. 
Those skilled in the art will recognize that the present invention may be implemented in 
hardware, software, or a combination of hardware and software. It should also be 
appreciated from the outset that one or more of the function^ components may 
alternatively be constructed out of custom, dedicated electronic hardware and/or 

20 software, without departing from the present invention. Thus, the present invention is 
intended to cover all such alternatives, modifications, and equivalents as may be included 
within the spirit and broad scope of the invention as defined only by the hereinafter 
appended claims. 
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